home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / dcom / modems-part1 / 9584 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  8.1 KB
  1. Path: news.gate.net!not-for-mail
  2. From: dhaire@gate.net (doug haire)
  3. Newsgroups: comp.dcom.modems
  4. Subject: Re: Is USR going to support 42bis+ on future courier upgrades?
  5. Date: 29 Mar 1996 01:59:32 -0500
  6. Organization: CyberGate, Inc.
  7. Message-ID: <4jg1ok$1mti@seminole.gate.net>
  8. References: <4j2fv1$8kf@nnrp1.news.primenet.com> <4j2iun$a3t@newsbf02.news.aol.com> <4j3r1f$1tc4@seminole.gate.net> <4j468j$gg1@drencrom.insync.net> <4j68or$nug@navajo.gate.net> <4j7iai$qcc@drencrom.insync.net> <4jbasq$102o@navajo.gate.net> <4jd6e0$kbo@dr
  9. NNTP-Posting-Host: seminole.gate.net
  10. encrom.insync.net>: 
  11. X-Newsreader: TIN [UNIX 1.3 950824BETA PL0]
  12.  
  13. Greg Bretting (bretting@insync.net) wrote:
  14. : On 27 Mar 1996 07:04:42 -0500, dhaire@gate.net (doug haire) wrote:
  15. : 
  16. : [snip]
  17. : >: What does _that_ have to do with anything?  You said above that you were
  18. : >: using a null modem cable, and if that's the case then my LapLink example is
  19. : >: perfectly valid because it's essentially the same setup except for
  20. : >: different application software being used.
  21. : >
  22. : >Bingo! The same thing EXCEPT for the software involved. You are using 
  23. : >software designed to dedicate all of the CPU to the task. That's why I 
  24. : >said apples and oranges.
  25. : 
  26. : Well, let's see - LapLink is designed to transfer data to and from a serial
  27. : connection, perform error checking, and doing disk I/O.  How does this
  28. : substantially differ from the comm software you were using?
  29.  
  30. Because the comm program is not dedicating all processor time to the 
  31. transfer.
  32.   
  33. : >If you don't understand the difference between using LapLink and running 
  34. : >a comm program protocol on a null modem cable at full speed then you 
  35. : >aren't grasping the concept.
  36. : 
  37. : See above...
  38.  
  39. Like I said, you aren't grasping the concept.
  40.  
  41. : >: >: >When the common computer software platform is capable of handling 115200 
  42. : >: >: >properly perhaps we can then consider the 230k UART speed.
  43. : >: >: 
  44. : >: >: Well, DOS 6.2 is pretty common, and I know that I've been able to (almost)
  45. : >: >: saturate the port at 115200 without any errors.  Here's a log from one such
  46. : >: >: test using QModem Pro for DOS, a Courier V.34 external, and plain 16550
  47. : >: >: UART:
  48. : >: >: 
  49. : >: >: 22:40:52  09-14-95  Online Timer Started
  50. : >: >: 22:42:00  09-14-95  Download File(s).  Protocol : Zmodem
  51. : >: >: 22:42:01  09-14-95  ++ File 1MEGTEST.RUN
  52. : >: >: 22:43:34  09-14-95  ++ End of file
  53. : >: >: 22:43:34  09-14-95  ++ Chars Per Second    : 11272
  54. : >: >: 22:43:34  09-14-95  ++ Effective Percent   : 0%
  55. : >: >: 22:43:40  09-14-95  Elapsed Online 00:02:48
  56. : >: >
  57. : >: >Sure and I have also. In fact, I posted several articles showing this on 
  58. : >: >transfers between computers over phone lines and modems. That's not, of 
  59. : >: >course, what I was talking about here and it has little to do with my point.
  60. : 
  61. : But the above _does_ illustrate a case where a common DOS platform
  62. : functions well at a 115200bps DTE rate, which is a possibility you seemd to
  63. : take issue with in your "When the common computer software platform is
  64. : capable of handling 115200 properly perhaps we can then consider the 230k
  65. : UART speed." comment.
  66.  
  67. The port speed is not truly relevent because the modem is controlling the 
  68. flow to the port. The modem is effectively controlling the port, the CPU 
  69. is not.
  70.   
  71. : >: Then I obviously am missing your point; I interpreted it to be that you
  72. : >: felt 115200 DTE rates were unworkable on DOS platforms, let alone 230,400,
  73. : >: and that discussion of DTE rates > 115200 were pointless since 115200
  74. : >: didn't work very well on most platforms.  I then provide two examples, one
  75. : >: using a null modem connection and another a dial-up session with an
  76. : >: external modem, that seem to contradict what you are saying.  
  77. : >
  78. : >No, I offered that 115200 DTE rates were more than adequate for current 
  79. : >operating system platforms in the real world. That having a port set to 
  80. : >230k (and a modem that would accept that) is unnecessary and simply 
  81. : >advertising hype.
  82. : >
  83. : >You offered a link using a specialized piece of software as a counter to 
  84. : >this. Different game.
  85. : 
  86. : To begin with, I wasn't arguing that 230.4Kbps DTE rates made sense - I was
  87. : addressing your apparent (to me, anyway) claim that DOS-based platforms
  88. : weren't up to the task of supporting 115.2Kbps port speeds.  Let's also not
  89. : forget the example I offered involving a fairly common DOS based comm app
  90. : (Qmodem Pro, in case you forgot).
  91.  
  92. And I stand by what I said. I would like to see someone with a Hayes to 
  93. Hayes connection at 28800/28800 with ports open at 230k at each end send 
  94. a file and report the results so we can see what happens.
  95.   
  96. : >: Not only that, but I know for a fact that I can connect two modems to _one_
  97. : >: DOS machine and pass data full-duplex (simultaneous send and receive of the
  98. : >: same file) between the ports at 115200 without errors.  This is normally
  99. : >: how I run throughput testing on modems, using SoftArt's HowFast v1.65
  100. : >: testing software running under DOS, on a wide variety of machines.  
  101. : >
  102. : >How do you connect two modems and pass data at 115200 between them? 
  103. : >Answer: you don't. You pass data from a port to a modem on one end and 
  104. : >from a modem to a port on the other at that speed; between the modems, 
  105. : >you are limited to the DCE rate of the modems.
  106. : 
  107. : What, did we forget entirely about the subject of this thread - namely,
  108. : compression?  The DCE-DCE rate isn't the important part, it's the rate at
  109. : which the modem presents data _after compression_ to the DTE - which,
  110. : depending on the file, can be substantially higher than the DCE rate and
  111. : can under certain circumstances approach the limit of the port speed.
  112. : Regardless of whether we are talking about a NMC or modem call with data
  113. : compression enabled, the examples that have been discussed involve data
  114. : rates being presented to the DTE at or near it's limit (as configured) of
  115. : 115.2Kbps.  Unless I'm missing something (always a possibility I'm willing
  116. : to accept), there isn't much difference between a NMC connection that
  117. : presents data to the DTE at 115200 and a modem with data compression
  118. : enabled operating at a sufficient speed and passing highly compressible
  119. : data to the DTE at speeds very closely approaching the limit of the port.
  120.  
  121. The rate the data is sent to the port is limited by the modem's ability 
  122. to efficiently decompress the data brought in from the line. In essence, 
  123. you have the modem processor controlling the port of the receiver.
  124.  
  125. : Not only that, but keep in mind that in the above example, only _one_ CPU
  126. : and DOS environment is servicing the interrupt load for _both_ ports.
  127.  
  128. Only one port: the receiving unit. And, even there, it is subject to the 
  129. processing power of the modem to send to the port. The port is not fully 
  130. controlled by the CPU on the computer in that situation. Remove the 
  131. modems and you have one CPU (the receiver) trying to control both ports 
  132. and it does a poor job.
  133.  
  134. : >: Doug, I didn't just start doing this stuff yesterday - I know for a fact
  135. : >: that MS-DOS is perfectly capable of supporting 115200 DTE rates, and I've
  136. : >: demonstrated that on dozens of machines and literally hundreds of modems
  137. : >: during the course of testing these things, using all sorts of software, and
  138. : >: I know that it works.  
  139. : >
  140. : >Good, then you can simply ignore what I said and hit Enter. Or you can 
  141. : >discuss this without bringing in specialized software designed to 
  142. : >overcome DOS's limitations.
  143. : 
  144. : Well, okay then, let's deal with the examples I've posed so far that aren't
  145. : "specialized" software - namely, the QModem Pro log I posted previously and
  146. : the Procomm Plus/Win 2.11 screenshot I uploaded to alt.binaries.misc (which
  147. : I posted yesterday, have you seen it?)- both of which demonstrate
  148. : throughput on a DOS platform in excess of 11,000 cps.  Whatever the
  149. : limitations of DOS may be (and I'm not saying there aren't any), it doesn't
  150. : take exotic programming to overcome them - it would appear to me that just
  151. : about any competently written and properly configured comm app will do just
  152. : fine.
  153.  
  154. Just do what I did. Link two computers up via a null modem cable and run 
  155. the comm program of your choice in each computer with the ports locked at 
  156. 115200 and then come back with the results, ok?
  157.  
  158. That's all I ask.
  159.  
  160.